Attorney's Docket No.: 10559/457001 / P10868 



APPLICATION 



FOR 



UNITED STATES LETTERS PATENT 



TITLE: NETWORK NODE CONFIGURATION 

APPLICANT: RAVI L. SAHITA AND DAVID M. DURHAM 



CERTIFICATE OF MAILING BY EXPRESS MAIL 

Express Mai! Label No. EL724384445US 

I hereby certify that this correspondence is being deposited with the 
United States Postal Service as Express Mail Post Office to Addressee 
with sufficient postage on the date indicated below and is addressed to 
the Commissioner for Patents, Washingjen, D.C. 20231. 



///March 2$ 


^20(11 


Date of Deposit ff*^? ' 

/A V 


/ 

J 




Signature 










Gil VaJ 


/as 



Typed or Printed Name of Person Signing Certificate 



Attorney Docket No. : 10559/457001/P10868 



NETWORK NODE CONFIGURATION 
[0001] This invention relates to the configuration of a 

network node. 

BACKGROUND 

[0002] A managed network typically includes several 
managed nodes that are under the centralized control of a 
management station. Each managed node maintains configuration 
data that describes how that managed node is to operate. As 
part of its management function, the management station may 
need to modify this configuration data. This requires that 
the managed node and the management station establish 
communication. A suitable protocol for establishing 
communication between a management station and its managed 
nodes is SNMP (Simple Network Management Protocol) . 
[0003] With SNMP as the communication protocol, each 
managed node maintains its configuration data locally in a 
management information base ( "MIB" ) . Because the management 
node and the management station must communicate across a 
network, the management station cannot directly access the 
MIB of a managed node. Instead, the management station sends 
a message to an SNMP agent executing on the managed node. The 
SNMP agent then operates on the MIB in response to 
instructions contained in that message. 
[0004] To modify configuration data, a network 
administrator at the management station identifies the 
objects in the MIB that are to change. The administrator then 
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sends SNMP "set" requests to individually change those 
objects . 



[0005] 



BRIEF DESCRIPTION OF THE FIGURES 

FIG. 1 shows a managed network; 



[0006] 



FIG. 2 shows a managed node; and 



[0007] 



FIGS. 3 and 4 are flowcharts. 



[0008] 



DETAILED DESCRIPTION 

FIG. 1 shows a managed network 10 in which a 



management station 12 communicates with several managed nodes 
14a-d using the common open policy protocol (COPS), and in 
particular, using an extension of that protocol, COPS-PR, 
that is specifically adapted for policy provisioning. Each 
managed node 14a-d thus functions as a policy enforcement 
point ("PEP") and the management station 12 functions as a 
policy decision point ("PDP") . The managed nodes 14a-c can be 
routers, bridges, hosts, printers, and similar devices. 
[0009] The use of COPS-PR to communicate management data 
between managed nodes 14a-d and a management station 12 
enables a network administrator to specify a desired 
configuration at a more abstract level than that which can be 
specified with SNMP. In effect, COPS-PR acts as a compiler 
that translates the more abstract description of a desired 
configuration into the elementary operations supported by 
SNMP for operating on the MIB. 
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[0010] FIG. 2 shows a representative managed node 14a in 
more detail. The managed node maintains a local MIB 16 that 
contains configuration data as well as various operating 
statistics. An SNMP agent 18 in communication with the local 
MIB 16 modifies or retrieves objects in the local MIB 16 in 
response to received instructions. As indicated by the arrows 
in FIG. 2, when the SNMP agent 18 receives a "set" 
instruction, it modifies an object in the local MIB 16. When 
the SNMP agent 18 receives a "get" instruction, it retrieves 
an object from the local MIB 16. 

[0011] In a conventional network, the SNMP agent 18 
receives "get" and "set" instructions from SNMP messages sent 
by the management station 12. However, in the managed network 
10 of FIG. 1, the management station 12 emulates a COPS PDP 
by sending COPS-PR messages to managed nodes. These COPS-PR 
messages include attached objects that specify the desired 
changes in the configuration. The COPS-PR messages are not 
understood by the SNMP agent 18. As a result, it is necessary 
to provide a translator that converts a COPS-PR message into 
a form understood by the SNMP agent. 

[0012] A COPS-PR shim layer 20 executing on the managed 
node 14a provides this translation function. The shim layer 
20 is configured to emulate a COPS PEP by receiving COPS-PR 
messages from the management station 12 and providing a 
corresponding sequence of calls to the API (application 
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program interface) of the SNMP agent 18. The shim layer 20 is 
also configured to receive data extracted from the local MIB 
16 by the SNMP agent 18 and to repackage that data into a 
corresponding COPS-PR messages for sending to the management 
station 12. 

[0013] Because local MIBs vary from one managed node to 
the next, the shim layer 20 does not know precisely which 
objects in the local MIB 16 are to be accessed or modified in 
response to a COPS-PR message from the management station 12. 
For this reason, the shim layer 20 maintains communication 
with an auxiliary MIB 22 that stores metadata descriptive of 
data stored in the local MIB 16. 

[0014] The metadata stored in the auxiliary MIB 22 
includes a specification of data from the local MIB 16 that 
is to be supplied to the management station in response to a 
COPS-PR "REQ" or "RPT" message and a specification of data 
from the local MIB 16 that is expected from the management 
station upon receiving a COPS-PR "DEC" message. The auxiliary 
MIB 22 thus functions as a dictionary available for reference 
by the shim layer 20. 

[0015] As an example, a managed node 14a can be a router 
in which the local MIB 16 includes statistics on the number 
of broadcast packets that have passed through the router. 
These statistics are identified by an object identifier 
("OID") within the local MIB 16. Periodically, the management 
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station 12 may request reports from that managed node 14a, 
Such a report would include a large number of statistics in 
addition to the particular statistic described above. 
[0016] In collecting statistics from the managed node 14a, 
it is more efficient to issue a single request for a report 
rather than to issue a sequence of requests for each 
individual statistic within the report. To accomplish this, 
the auxiliary MIB 22 includes all OIDs that identify 
statistics to be retrieved when the management station 12 
requests a report. Upon receiving a COPS-PR communication 
requesting a report, the shim layer 20 searches the auxiliary 
MIB 22 for all OIDs associated with a request of that type. 
The shim layer 20 then formulates the individual calls to the 
API of the SNMP agent 18 to carry out the request. This 
enables the network management station 12 to issue what 
amounts to a macro instruction and to have the shim layer 29 
decompose that macro instruction into its elementary parts. 
[0017] The metadata in the auxiliary MIB 22 is pre- 
specified by a network administrator. The network 
administrator provides the metadata to the auxiliary MIB 22 
through an SNMP session with the managed node 14a or by using 
the CLI (command line interface) of the managed node 14a. 
Alternatively, the network administrator can provide the 
metadata to the auxiliary MIB 22 remotely through a COPS-PR 
protocol session that uses a client type different from the 
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client type used for other COPS-PR traffic between the 
management station 12 and the managed node 14a. On the basis 
of this client type, the shim layer 20 distinguishes between 
COPS-PR communications for accessing the auxiliary MIB 22 and 
COPS-PR communications for accessing the local MIB 16. Once 
the auxiliary MIB 22 has been built, the shim layer 20 can 
then begin operation. 

[0018] The auxiliary MIB 22 can also include a listing of 
objects in the local MIB 16 whose values are to be reported 
periodically to the management station 12 for accounting 
purposes. In this embodiment, the shim layer 20 monitors the 
elapsed time since the last report to the management station 
12. When the shim layer 20 determines that another accounting 
report is due, it formulates calls to the API of the SNMP 
agent 18 to retrieve the desired object values. It then 
packages those values in a COPS-PR message and sends that 
message to the management station 12. 

[0019] FIG. 3 shows the response of the shim layer to a 
COPS-PR communication received from the network manager. The 
shim layer receives 24 the COPS-PR message and obtains 26 
metadata from the auxiliary MIB. This metadata enables the 
shim layer to identify the objects in the MIB that are to be 
accessed in connection with the COPS-PR message. The shim 
layer then formulates 28 a sequence of one or more calls to 
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the API of the SNMP agent. Collectively, these API calls 
carry out the instructions in the received COPS-PR message. 
[0020] FIG. 4 summarizes the response of the shim layer to 
messages received from the SNMP agent. The shim layer 
receives 32 messages from the SNMP agent and accesses the 
auxiliary MIB to obtain 34 metadata. This metadata enables 
the shim layer to formulate 36 a COPS-PR message 
corresponding to the SNMP agent's messages. The shim layer 
then sends 38 this COPS-PR message to the network manager. 
[0021] Other implementations are within the scope of the 
following claims: 
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